Analogy: Factory assembly line. CI = quality control at each station (automated tests). CD = the conveyor belt delivers the product to the customer automatically. Without it, you're hand-carrying each product.
Why CI/CD for Serverless?
Repeatable, consistent deployments every time (no manual errors)
Many small pipelines - one per microservice/function
Rapid iteration - developers push, pipeline handles the rest
Automated testing at every stage (lint, unit, integration, e2e)
Safe rollbacks - canary deploys catch issues before full traffic
Without CI/CD: Baking one cake manually each time (error-prone, slow). With CI/CD: Automated bakery line - same quality every time, scales to 1000 cakes.
AWS Developer Tools for CI/CD
Also works with: GitHub Actions, GitLab CI, Jenkins, Terraform
AWS SAM Pipeline Features
# Initialize a CI/CD pipeline for your SAM app
sam pipeline init --bootstrap
# Creates:
# - IAM roles for pipeline stages
# - S3 bucket for artifacts
# - Pipeline configuration (CodePipeline or GitHub Actions)
# - Separate configs per environment (dev/staging/prod)
# Deploy pipeline
sam deploy --guided # or use the generated pipeline config
Key SAM Deployment Features
AutoPublishAlias - automatically publishes new version + updates alias
Q1: What does DeploymentPreference: Canary10Percent5Minutes do?
B) 10% traffic for 5 min, then 100% Canary sends a small portion of traffic to the new version. If alarms stay healthy for 5 minutes, it shifts 100%. If alarms fire, it rolls back automatically. A: Traffic shifting, not account selection. C: All code deploys, traffic is what shifts. D: No waiting before deploy - traffic shifts immediately to 10%.
Q2: Why use separate AWS accounts per environment?
B) Isolate blast radius + security boundaries A dev mistake can't break prod. Each account has its own IAM, quotas, and network isolation. Also enables separate billing. A: Same pricing regardless of account. C: You can request increases in any account. D: Stack limits are per-account but that's not the primary reason.
Q3: What triggers an automatic rollback in a SAM safe deployment?
B) CloudWatch Alarm entering ALARM state You define alarms (Errors > 0, Latency > threshold) in the DeploymentPreference. If any alarm fires during the canary period, CodeDeploy automatically rolls traffic back to the previous version. A: Manual approval is a gate, not auto-rollback. C: Build failures prevent deploy, don't roll back. D: Unrelated to deployment.
Q4: What do PreTraffic and PostTraffic hooks do?
B) Run validation Lambdas before/after traffic shift PreTraffic runs before ANY traffic goes to new version (e.g., check DB migrations). PostTraffic runs after shift completes (e.g., integration tests). Either can fail the deployment and trigger rollback. A: Concurrency is separate. C: You could do this, but that's not the primary purpose. D: DNS is handled by aliases, not hooks.
# Deploy first version
sam build && sam deploy --guided
# Make a code change (introduce a small update)
# Redeploy - canary begins
sam build && sam deploy
# Watch the canary in real-time:
aws codedeploy get-deployment --deployment-id DEPLOYMENT_ID
# In CloudWatch: watch alias traffic weights shift
# 10% to new → wait 5 min → if healthy → 100% to new
What to Show in Console
Service
Demonstrate
CodeDeploy
Show deployment in progress, traffic weight shifting 10% → 100%
Lambda
Show alias with weighted routing (V1: 90%, V2: 10%)
CloudWatch
Show alarm status during canary period
Rollback test
Deploy bad code, watch alarm fire + auto-rollback
Module Summary
Implement CI/CD to make multiple deployment pipelines manageable
Use SAM/CDK to simplify stack + pipeline creation
Use deployment hooks + traffic shifting for safe production deploys
Define one SAM template with parameters across environments
Separate accounts per environment (dev/staging/prod)
Use Parameter Store / Secrets Manager for environment-specific config